Broadband - Trouble Ticket API - TMF621

Within PXC's Trouble Ticket V1 API, there is Event Notification functionality which allows partners to consume Trouble Ticket event notifications, which are pushed out to partners in real time. This ensures the latest Trouble Ticket update and lifecycle event can be received and processed by partners as soon as it happens and ensures end customers are kept up to date. These notifications are delivered to the partner’s configured /listener endpoint. This function also removes the requirement to poll the retrieveTroubleTicket endpoint for Trouble Ticet updates.

On-Boarding Process

To activate PUSH Trouble Ticklet event notifications on your account, you will need to provide an API endpoint configured to the PXC Trouble Ticket event notification schema, along with a basic authentication Username and Password to the PXC API team via api@pxc.co.uk.

Each notification contains:

• The relevant ticket update data in the event.troubleTicket block (few samples can be status, statusChangeReason, statusChangeDate)

• The original id of the ticket

• A Correlation-Id in the HTTP header, matching the request that triggered the update (e.g., a partner POST or a internal-driven system action)

Important:

• Partners must ensure their /listener endpoint is available and responds with 200 OK

• Push notifications are retried on failure (typically with exponential backoff), but persistent errors may result in dropped updates

• Notifications are one-way and do not expect a business response - they are for informational and event tracking purposes only

All notification events are TMF621 vanilla compliant. Examples include:

• TroubleTicketInformationRequiredEvent

• TroubleTicketAttributeValueChangeEvent

• TroubleTicketStatusChangeEvent

• TroubleTicketResolvedEvent

• TroubleTicketCreateEvent

These event types are part of the TMF621 vanilla event model and conform to TMF’s event notification pattern (eventType, eventId, event.troubleTicket, etc.). This implementation supports both modes of eventing: A separate event per updated attribute, and A combined event when multiple fields are updated in a single activity. Event consumers should be prepared to receive either format.

Event Types by Status Transition

The TroubleTicketStatusChangeEvent is used to represent all status changes, including partner-triggered transitions like cancellation and reopening.

The TroubleTicketResolvedEvent is emitted in addition to a status change event when the ticket is marked as resolved.

All transitions listed below are aligned with the TMF621 lifecycle model.

• Cancellation is allowed from any state that is valid per TMF621 - This is fully captured in the table under Any → cancelled.

• Reopen logic (resolved → inProgress) is explicitly included and mapped to a TroubleTicketStatusChangeEvent.

Although the table below shows the logical status transitions, in practice you may receive one or more events around a given transition, and events may arrive very close together. Event delivery order is best-effort only. Integrations MUST therefore be tolerant of:

• multiple events for the same transition, and

• events that appear to “reverse” a previous status (for example, an update that sets an appointment followed by another that cancels it).

In all cases, the current ticket state from GET /troubleTicket is the definitive source of truth.

Guidelines: Which Event Should I Consume?

Examples of Downstream Actions